Rohde & Schwarz MXO 4 Oscilloscope: A Review!

RoadTest: R&S® MXO 4 Oscilloscope

Author: shabaz

Creation date: 11 Apr 2023

Evaluation Type: Test Equipment

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: The MXO 4 is supposed to compete with Tektronix MSO 4-series, and Keysight 4000 X-series, however some MXO 4 features compare extremely favourably with other manufacturer 6/6000-series models.

What were the biggest problems encountered?: Some bugs, although not showstoppers. The product is new and complex, so that is understandable, but I hope the manufacturer can resolve them as soon as possible. I would like to see a couple of the MXO features to behave differently or be extended, explained in the review.

Detailed Review:

MXO 4 Series Oscilloscope Review

Contents

IntroductionPhysical Hardware and its UsabilityWorking with Signals and High ResolutionCurrent, Power, and Noise Measurements    Ferrites and Inductors    FPGA Power Measurement    Zooming in for DetailSpectral Analysis    Examining Power Supply Noise Spectrum    Examining RF Modulation    EMC Testing    Conducted Emissions Testing    Radiated Emissions TestingWaveform Generation    Frequency Response Analyzer: Audio Amplifier Characterization    RF Mixer Testing    LoRa Testing: Arbitrary Waveform GenerationMemory Depth, Logic, and Serial Bus Decode    Debugging Software and Protocol Stacks    RS-485 DMX TestingOrder CodesSummary

Introduction

Check out the unboxing video to see what’s being reviewed here!  R&S MXO 4 Series Oscilloscope - What's in the Box?  

The MXO 4 display is large, offering 13.3” of visible full HD (1920 x 1280). The entire oscilloscope front view, along with its controls, is as large as a 17” monitor on your desk; it will take up the same real-estate as a monitor with a stand.

The instrument looks as good and appears as well-made as any equipment one might find in a lab or office. The touch-screen is bright and detailed, and some of that very high-quality image will be lost if the instrument is placed high above eye level on a shelf, so you’ll want it either on the desk or at eye level with a monitor arm with VESA mount.

The screen is so bright and clear I didn’t realize I had not removed the disposable shipping screen protector film for several weeks! The photos here are with that protector film accidentally still attached!

The instrument does a lot, so there will be lots of interaction with it, and therefore its ergonomics and usability are more important to get right than with older oscilloscopes; this is an instrument that you’ll definitely want in a convenient position so you can control it frequently. There are plenty of features to help with that, and they are covered further below.

The MXO 4 has perhaps the highest-resolution data acquisition I’ve seen in general-purpose oscilloscopes. I was glad to see that this high-res hardware is matched with software features to extract and visualize detail from measured signals. It’s pretty astonishing seeing it in action, and the benefits of the high resolution are covered in several of the sections below.

Another neat hardware feature is that users get the same power/performance regardless of purchase bandwidth. Everything is software-upgradeable so that even if a firm purchases the lowest-range option, they still immediately benefit from the same 200 Gbit/sec multi-cored data processor chip that the highest-range option has. The low-range option is not crippled with poor performance. This means users are getting a lot of value for money purchasing the base unit if they don’t need the high bandwidth. Still, it can be upgraded later as desired. Plus, the MXO 4 is lower-cost than some competitors anyway. It is hard to make a price comparison since products are not like-for-like. Although Rohde & Schwarz have labeled the MXO as a 4-series ‘scope, some properties are firmly in competitor 6000 series scope territory.

For this RoadTest, I tried to use the product in various scenarios, and generally, I found the MXO 4 worked great at everything I threw at it. There are, for sure, bugs (which is unsurprising for a new feature-rich product; they have been reported, so I’m hoping they should be fixed at some point), but for the most part, there are workarounds. The instrument has been rock-solid; it doesn’t crash or lock up. The user interface is extremely pleasing in looks. It has a similar look and feel to other R&S equipment, and everything is clear, legible, and intuitive. However, the instrument packs a lot on the display, and it is possible to get in situations where it is hard to position everything perfectly because some things cannot be easily selected using fingers or a mouse. I think it is a solvable problem, but I can imagine it is, unfortunately, lower on the list of priorities if R&S is working on bugs or features.

The MXO 4 remote control capability has been flawless, it just works, and the remote commands are extremely well-documented.

In day-to-day use, the performance has been great. Some things have slower performance than expected, but I suspected that was because R&S still needed to offload some things from the application processor to the 200 Gbit/sec MXO-EP processor. This has proven to be right because (at the time of writing this), just a few days ago, new firmware was released, and the accompanying notes mention that some functions are now offloaded to that high throughput MXO4-EP. I have no detail about that high-performance data processor, but having worked in other organizations that used very high throughput processors in their products, I can imagine it is a highly multi-cored device that can have its cores consuming sampled data, there may be a dispatcher that pushes content to cores as they free up, and the developers likely have a C software development kit (SDK) to port across functions that were traditionally done on the application processor. It would be unsurprising to see MXO 4 performance increase in many ways over the coming months and years as more and more features are offloaded or natively developed for the MXO-EP.

A video review is coming shortly (the video has been recorded, it just needs to be completed), allowing you to judge how the instrument performs in action with your own eyes.

Physical Hardware and its Usability

The screen is great, and you’ll want to see it face-on. If your desk (like mine) doesn’t have a lot of space, then the VESA mount capability is helpful. Alternatively, the instrument could be placed on a monitor riser-type product to free up some desk real estate.

The instrument has a massive fan; it runs slowly and is very quiet as a result. I also liked that there were lots of USB interfaces, plenty for a mouse, keyboard, USB memory stick for screenshots, and so on. The HDMI connection could come in handy, it simultaneously mirrors what is being displayed on the in-built screen.

There are vents on one side for air ingress. Everything feels well constructed.

Like many modern oscilloscopes, separate controls for each channel are gone, replaced with LED-lit channel selection buttons (C1-C4) and LED-ring-illuminated volts-per-div and Y-position controls. You have to keep an eye on the ring colors to know what channel is selected and an eye on which channel buttons are illuminated to see which channels are enabled (or look at the traces). For me, this takes a bit of getting used to, but it is what it is. For sure, it takes longer to operate these controls than individual controls, but nowadays, there are so many settings per channel that it makes less sense to dedicate per-channel control knobs just those two traditional per-channel controls; the operator has a wealth of other things that may need configuring too, so other buttons and the graphical menu system at some point has to be used anyway.

Speaking of other buttons, R&S has managed to incorporate a very large display but also around 30% more physical buttons than some other large-screen ‘scopes such as the Tektronix MSO44. The Keysight ‘scopes traditionally have more physical buttons, but the MXO 4 isn’t far behind. The hard rubber buttons feel fine, and most of them illuminate to show status where it makes sense.

There is a multi-purpose control knob that adjusts different parameters depending on what is highlighted in the menus. Coming from using Tektronix scopes, I frequently mixed it up with the Volts/div control because it is positioned below it. I’ll soon get used to that!

Generally, the physical controls are pleasing; they are easy to read and feel fine. All of the control knobs can be pushed where it makes sense, for instance, to reset the horizontal position or the cursors.

Like other R&S equipment, there is a dedicated button to capture screenshots quickly. There is also a Default button to reset things as with other ‘scopes.

Unlike most ‘scopes, there is a dedicated button to bring up the spectral analysis capabilities. With this instrument's performance, it will become second nature for users to quickly work with both time and frequency domain views to more fully understand signals of interest.

I wish the instrument had a full physical numeric keypad. Granted, it would take up significant front panel space, and it is rare on ‘scopes (the older Tektronix MDO3000 had it, but Tektronix dropped that on later models).

I didn’t initially like the supplied RT-ZP11 700 MHz ‘scope probes because the cable is not as flexible as that on Tektronix probes. Plus, the high-end passive probes on Tek ‘scopes can automatically self-compensate without manual tweaking. However, on the plus side, the R&S probes are a lot smaller and finer, which makes it easier to attach to dense circuits. The probes come with various accessories, as shown in the photo below, but optionally an even wider range of add-ons can be purchased in a probe accessory pack.

The logic probe option is great; the option comes with two long (1-meter length) 8-way cables that plug in via stretched-HDMI-like connectors to the MXO 4. The other end attaches to a spider adapter box (with active circuitry inside; it gets slightly warm in use) with extremely flexible cables to attach to the circuit under test. Plenty of accessories are supplied, and normal pin headers and sockets are used, which is great if any accessories are lost.

Working with Signals and High Resolution

The MXO 4 has a high-resolution converter (12-bit), but ordinarily, that alone would not be good enough in an oscilloscope. The scope would also need to have low noise, low jitter, and, equally importantly, useful methods for users to be able to visualize the signal detail.

One feature that works very well is to drag-to-zoom. In the screenshot below, I could see the small amount of jitter and noise on the signal.

The signal is from a fast-edge square wave generator; I connected it to the ‘scope using a coax cable.

On normal ‘scopes, if you do a single capture, the thin line can be very misshapen due to noise since there is no persistence of vision or signal averaging. Much of the characteristics of the actual signal are now lost in that capture. With high-resolution zoom, such a situation would be much worse, and a single capture could look ugly and become unusable.

One difference between the MXO 4 and other scopes is that the normal Single capture button on the ‘scope can work in a slightly different mode to overcome this!

You can dial in any value into an acquisition menu item called N-single, which means that each time the user presses the Single button, additional captures are used to build up the trace. This is brilliant and makes me wish other ‘scopes did the same thing because often, the user is forced to use the Run/Stop button in an attempt to get a more usable trace capture.

Another neat feature is that every trace used to create that display in the screenshot above is accessible individually. The MXO 4 stores each trace in a History buffer, and the user can view each of them individually or even replay the buffer at any desired speed. For instance, if you spot an anomaly amongst the normally expected capture, you can replay the event repeatedly. This actually works in the normal Run/Stop mode too. For the example above, the MXO automatically captured more than a million acquisitions within a second (about as fast as I could hit the button to run and then stop), and then I was free to replay any of them (or any range).

One other key feature worth mentioning briefly (it is addressed in more detail further down in the review) is the need for spectral analysis. The human eye cannot identify signal artifacts in a time domain view that would be easily discernible in a frequency domain view. With a high-res ‘scope, decent spectrum analyzer-type capabilities are essential. Thankfully it doesn’t disappoint; the rapid real-time ‘scope view has to be seen to be believed. There’s more on that later.

Current, Power and Noise Measurements

Ferrites and Inductors

With the high power density needed for modern DC-DC converters, it becomes essential to be able to measure ferrite and inductor performance, especially for custom-wound parts, so that they can be optimized for the required circuit. I wanted to see if I could achieve decent inductor measurements with the MXO 4. Inductors are commonly made of wire wound around ferrite material because it increases the inductance compared to an air core.

Ferrite material will saturate, i.e., its magnetic flux density can be increased, but if it reaches a limit, it cannot increase any further. Therefore, if an inductor is formed with a ferrite core, then as the current rises in the inductor, it will cause the magnetic flux density to increase, but the inductance will drop off as the ferrite saturates. The drop in inductance causes a huge increase in current since the inductor no longer has its original inductance.

With the MXO 4, I wanted to be able to see the current in the inductor. I used a current sense resistor in series with the inductor and switched the current on/off with a MOSFET, controlled by pulses from the MXO’s waveform generator.

Ordinarily, one would need to increase the value of the sense resistor to get a measurable value. However, with the MXO 4, I went straight away for the lowest value current sense resistor I had; 10 mOhm.

For my test inductor, I wound 20 turns of wire on an FT-37-61 ferrite core; this should achieve 22 uH of inductance (the free coil64 program can be used to determine this). I built the circuit on a board that can also act as a MOSFET or diode testbed:

I was expecting to calculate the inductance from the oscilloscope traces manually, but it was a good opportunity to try the built-in math capability.

The math capability is programmed in an unusual way, but it is not too bad. Each term needs to be calculated in separate math terms (up to 5 are available), and the subsequent terms can use preceding ones to construct a chain of math operations. Although the number of terms was enough to meet my current need, I think R&S should try to extend this in a future firmware revision and have a better way of chaining operations. That would future-proof it a bit, and there are simple things that I reckon are feasible with low overhead; I have made some recommendations in this area to R&S. The actual math performance while the MXO is running is pretty good and there have been improvements in the latest firmware (some of the math capabilities have been offloaded to the 200 Gbps MXO-EP processor).

For calculating the inductance, I used all of the terms; I scaled the voltage measurement in Math Channel M1, and then calculated a gradient in M2, inverted it in M3, scaled it further in M4, and then M5 was used to perform low-pass filtering.

It ran really fast! It would be possible to tweak the inductor in real-time and immediately see the results on the MXO (it is the blue trace in the screenshot below). I was extremely impressed. I never thought I could measure microhenry-level inductances with good precision in real time while seeing how the inductor saturates! The fact that it works for these relatively small inductance values makes it extremely useful for DC-DC converter design.

With such a setup, one could experiment with the inductor, for instance, heating it up and observing the measurements instantaneously.

Note that in the screenshot below, the initial hump in the green trace isn’t actually current in the inductor; it is a limitation of the testbed (the current sense connection picks up the signal from the MOSFET gate drive, plus the gate drive could do with more current; it doesn’t affect the measurement after the first couple of hundred nanoseconds). The results below were obtained with improved gate drive (reducing the gate resistance further); the measured inductor values are not significantly different.

I also liked that the waveform generator was easily usable to generate pulses for this testbed.

FPGA Power Measurement

Power consumption measurement is key for many circuits, particularly FPGA-based products, where it is non-trivial to estimate the consumption since it depends so much on the FPGA technology, implementation, and routing. There are power calculator/estimator tools within FPGA development environments, but it still needs to be checked in case of a difference. The best way to do this will be with either a current probe or an active differential probe. However, the high sensitivity of the MXO 4 should allow a direct connection to a current sense resistor. This would not be ideal because it has the severe restriction that the oscilloscope ground forms one end of the measurement. This also can cause differential-mode noise to become easily coupled into the measurement. Still, it was worth a try to see what’s possible!

The result was very promising but needs further work. For the test, I used a FPGA (Lattice iCE40 on an iCEstick development board) which was configured with a test project just to consume any realistic amount of power (it displayed a VGA test pattern) as well as toggle a test output pin at a slower rate. The total current consumption was around 100 mA for the whole system. Next, I connected the test pin to a 660-ohm resistance to the ground to simulate a 5 mA load. It was possible to clearly resolve the additional current demand on the system!

In principle, the measurement is straightforward:

However, in practice, since it suffers from the issues mentioned earlier, it can help to shield and route wires to minimize noise pickup.

I decided to use a very small sense resistor, 25 mOhm, simply out of curiosity to see what could be measured! To do this measurement, especially with a small sense resistor, takes a lot of care however, and it is still not ideal, because there is noise, and the MXO can easily resolve smaller signals provided I can find a way to deliver them as well as possible. I used homemade twisted-pair coax, but a better method could be to use a 4-layer PCB and use an internal copper plane to shield the sense traces. Another useful thing to do would be to use a small ferrite and a capacitor to do some low-pass filtering if needed.

I hope to extend this into a project for a passive current probe (with the ground limitation, i.e., it won’t replace a proper active differential probe or any isolated current probe) using a 4-layer PCB method.

Zooming in for Detail

The zoom capability is really well executed, and it allows very small differences or anomalies to become clearly visible. It’s as easy to use as it could be; as mentioned earlier, it is possible to finger-drag to draw a box around the area of interest (the box can be tweaked if necessary using the menu and finer controls than a finger if desired).

For this test, I merely applied a square wave to the MXO 4. At a normal vertical scale setting, any very slight imperfections are buried within a pixel or two. However, with the zoom capability, I could immediately see the effect of altering the square wave frequency to the (in this example) signal close to the falling edge of the square wave. Differences in the order of millivolts are discernible here! I think this slight imperfection is caused by a very small mismatch in impedance in the signal source and cable incidentally.

To do this test, I used the fast edge square wave generator mentioned earlier. It is great for seeing the difference in probing techniques. The acquired data is pretty stable; using the zoom capability, I can easily and repeatably see slight differences even in cable loss when the cable to the square wave generator is extended.

Spectral Analysis

The spectral analysis is pretty phenomenal. The MXO 4 doesn’t seem to perform just a normal FFT; instead, it might be using a CZT algorithm, but I’m purely speculating. All I know is that I’ve never seen this kind of performance from an oscilloscope or a traditional sweep spectrum analyzer. Saying that it is speedy still doesn’t really do it justice; check out the video to see it for yourself.

The spectral analysis isn’t a nice-to-have thing; it’s an essential thing for oscilloscopes, and especially with the MXO 4 because it extracts considerable use from that low-noise front end and the high-resolution ADC. The spectral analysis is necessary for a deeper examination of signals because it can use “processing gain” to pull out signals that are impossible to see from the normal time-domain view. ‘Scopes are under-used if the spectral analysis capability is not used. However, older ‘scopes do not make it easy.

Examining Power Supply Noise Spectrum

To investigate this, I connected up what I hoped to be a low-noise power supply to see what I could see.

Incidentally, at this point, I wanted to attach the probes to the test bed in a better way than using a long ground lead. It would be handy to have a way to convert the ‘scope probe to attach to 0.1” header pins. By coincidence, the probes seem to plug perfectly into 2.5 mm headphone jack sockets! A couple of crimp sockets were soldered to the socket, and then some polydoh can be used to secure it (or epoxy glue can be used). This solution applies sideways pressure on the ‘scope probe tip, but it doesn’t seem excessive, and it did not bend the tip. Please don’t blame me if you try it and it doesn’t work out well! The proper method is to purchase a probe accessory kit because it comes with a cylindrical attachment that will not apply sideways pressure as the jack socket does.

With hindsight though, I should have just used an SMA connector and capacitor in series for this particular test. Anyway, at least I now have a DIY adapter for the times when a higher impedance is needed!

The spectral view is very easy to configure; the span and bandwidth can be entered in a way similar to a dedicated spectrum analyzer, and a very fast spectrum view shows up. Peak markers can be switched on, and they very rapidly track the frequency content. Power levels can be measured, but in this case I was using the passive voltage probe and I was interested in amplitudes, so the vertical axis was set to dBuV. Seeing frequency content poking out above the approximate 10uV RMS (in this example) noise floor was effortless!

Now I could try to improve the supply, and it was immediately observable what effect a ferrite would have on the supply connection.

Within minutes I’d narrowed down the problem to the power adapter, and by swapping that out (it was an old Fairway Electronics AC-DC power adapter, and I replaced it with a Meanwell one) and adding a ferrite, I’d reduced the switching harmonics to content almost in the spectral view noise floor.

It is just as easy to peek into tinier segments of the RF spectrum; the screenshot below shows the spectrum from DC to 1 MHz; perfect for fine-tuning all manner of circuits for low noise!

Examining RF Modulation

I took a superhet receiver (it is a Tecsun R-909, a pretty awful radio but cheap), and it was fairly easy to tap into the Intermediate Frequency (IF) using the supplied ‘scope probe. The photo below shows the radio ripped out of its plastic case and placed in a DIY Perspex frame so that it can be used for probing various connections on it with an oscilloscope. It’s a convenient way to learn how a superhet receiver works.

The results were nothing short of stunning. I had not expected to be able to observe and control the spectrum view so clearly. It’s better than any dedicated spectrum analyzer I’ve used! It will update faster than a normal ‘swept’ spectrum analyzer. The display from the MXO 4 is more comparable to the views from high-end Software Defined Radio (SDR) equipment. The screenshot below shows an example capture of 500 kHz of spectrum, centered at about 10.7 MHz. A normal SDR might not even capture that portion of spectrum! The MXO 4 captures down to DC, of course.

What can’t be seen from the screenshot is the fast update! It has to be seen to be believed (please see the video!). Incidentally, that screenshot above is with a resolution bandwidth (RBW) of just 100 Hz. That’s already great, but I also tried 10 Hz, and that works too (albeit with a slower update). That’s as good as any typical spectrum analyzer, but there’s no (practical) limit. At 1 Hz RBW, with no other changes made to the remaining settings, the update period was 1.9 seconds. The MXO 4 allowed me to configure into the hundreds of milliHertz for this scenario too.

It's also possible to apply color settings to see the excursions of spectrum levels. There’s no noticeable slow-down when doing this either; it seemed just as fast. This is something that would be hard to do with a normal spectrum analyzer simply because the sweep takes so long.

I’d love to see a ‘waterfall’ display on the MXO 4 one day. It seems to be easy low-hanging fruit for R&S to implement if they wished to do so. I think it would be truly spectacular to see that! With some software changes, the MXO 4 could support a ton of stuff for RF enthusiasts, but perhaps that will slightly eat into spectrum analyzer sales! Anyway, already, the MXO 4 provides very welcome spectrum capabilities.

EMC Testing

Electronic circuits and products can emit unwanted noise in the form of radiated emissions, or conducted out through the power rail, known as electromagnetic compatibility (EMC) issues.

It is important to know how and what’s being emitted so that products can be designed to pass formal testing. The question was, can the MXO 4 (and more broadly, any test products with the typical maximum bandwidth provided by oscilloscopes in general) be useful as a platform for hardware design engineers to perform their own quick EMC testing as they develop the hardware, prior to formal testing in labs?

Using the MXO 4 would be attractive because of the fast turnaround time if engineers can use the same instrument for performing EMC tests on-the-fly, as they use for hardware development. I’d love to be able to quickly see what noise my circuit is emitting and how I can fix it!

From the experiments described below, the answer was found to be yes! For sure there are caveats, since firstly, for decent measurements, the user would need a test area set aside with grounding and a clean power supply and so on for repeatable results, and secondly, it wouldn’t replace more thorough testing at frequency ranges that are not supported with typical oscilloscopes. For instance, a circuit may well have spurious oscillations at say 5 GHz that would need a spectrum analyzer or receiver that supports that frequency range. The MXO 4 can support up to 1.5 GHz (I have the 500 MHz model, but it can be upgraded with a license purchase) and these ranges are sufficient to identify many EMC problems simply because radiated emissions tests can inevitably reveal a lot below 1.5 GHz since many (not all of course) radiated emissions can be the result of harmonics from lower-frequency clocks and switching. Besides, for conducted emission tests, this may just require testing to 100 MHz anyway. There are a lot of standards concerning the allowed limits, so you’d need to consult them.

To summarize all the above, the benefit would be that the engineer can do frequent EMC testing with the MXO during development, until they can subject their hardware design to higher-end equipment for testing.

Conducted Emissions Testing

The testbed that I used is shown below.

For measuring conducted emissions for any circuit/device-under-test, a test component called a line impedance stabilization network (LISN) is needed to isolate the variability of the power source from the signal levels that the MXO 4 will see. I used a homemade LISN pair, in a non-ideal environment, to see if it is even feasible. This minimal circuit that I used is part of standards but is replicated all over the Internet with various slight modifications, in particular, additional circuitry is often added to protect test equipment from transient voltages. In brief, the noise path from the device under test is through the connectors J1 and J2.

As suggested above, it would be preferable to dedicate space for such testing, with the equipment and physical setup as laid out in standards, so that tests are repeatable. There are IEEE and CISPR standards that explain all this; it can get pretty involved to set it all up, as the example diagram below shows. I did not use a proper EMC bench setup. However, as can be seen further below, there is a lot of value in even a non-ideal setup since not everyone has the space for a permanent EMC testbed.

 (Image source: Academy of EMC )

For now, my minimal setup was sufficient to explore if the MXO 4 could be usable. I was impressed! It was great to see the MXO 4 allows for spectral analysis on maths channels as well as the normal oscilloscope channels because this is very handy for separating the conducted and radiated emissions using a simple formula.

The constructed LISN is shown below. I used 20 turns of 0.7 mm enameled wire (22 SWG or 21 AWG) wound around an 8 mm drill bit to make the inductors. It was taped inside a biscuit tin for shielding.

For the device-under-test, I used a Raspberry Pi 3B attached to a capacitive touch display. Next, the outputs were observed on the MXO 4 with the power supply switched off, and it was possible to see the importance of equipment and wire placement to minimize the noise. Since I didn’t have a metal ground plane, I placed the LISN (in its M&S biscuit tin) on top of the metal power supply chassis, connected to its ground, and then placed the Pi + capacitive display on top of the metal biscuit tin : ) (This kind of pyramid of equipment, which works well in small spaces, I’m calling the shabaz ground pyramid EMC test method : ) The spectrum display with the power off was saved as a reference trace, and then the supply was switched on. I was expecting to see both differential-mode noise (for instance from DC-DC converters on the Pi and display board) as well as common-mode noise since there are plenty of high-frequency clocks and signals on the boards, which could couple to the ground. The common-mode noise can be seen by summing the two channels.

In a similar fashion, it is possible to see the differential-mode noise by subtracting the two channels. This is great, but ideally we want to see what sort of margin there may be compared to standards. This is done using limit lines that need to be applied against the spectrum output. If the output exceeds a limit line, then the device-under-test fails compliance tests.

Commercial EMC test software will come with appropriate files for running tests against standards. I instead created a simple JSON file format and saved it to my PC with an appropriate file name, such as cispr32_1.json.

Next, I wrote some code that would take that file name, along with the spectrum output from the MXO 4 (which can be saved as a CSV file), and chart it. Now one can easily see where the emissions levels lie with respect to the limit lines. It’s quite basic software, but I think it is a good start for users to document EMC measurements as a hardware design progresses. The Python code is on GitHub and is easy to run; just type the file names into the single Python file, and run it to generate the graphical output as shown below. The example output here shows lots of high-frequency content in the common-mode view, whereas the differential-mode view shows more lower-frequency content.

In summary, the MXO 4 worked well for conducted EMC tests, and I’m looking forward to further refining my setup with better filtering for the power supply and some transient protection added to the LISN.

Radiated Emissions Testing

It is also possible to use the MXO 4 for radiated emission testing. The high sensitivity of the instrument means that a preamplifier is not needed; plenty of output can be observed even with the smallest of H-field probes.

The probe in the photo above is pretty tiny (for getting close to components or even individual traces), and the output is easily visible on the MXO 4 with the spectrum analyzer processing gain, but often even on the time-domain view the content is visible to the eye. The probe is a DIY one; for best results, a commercial one can be used. Incidentally, I have a couple of spare DIY probes, so if anyone wants one, please let me know; I’ll be happy to send it for free (using the cheapest postage option I can find).

For the test, I used the fast edge square wave generator. I wanted a consistent way to position the probe for tests, so I used a homemade test jig that simply holds the probe vertically above a PCB trace.

The screenshot below shows the result; based on this, it would be possible to determine the response of the H-field probe!

Waveform Generation

The MXO 4 has a really nice built-in dual signal generator. It’s so useful I’m thinking of ditching a separate arbitrary signal generator I purchased a while ago; here’s why! – the MXO 4 waveform generator offers high output (10V peak-to-peak, or +18 dBm power) and is 16-bit! – perfect for a high-res ‘scope.

It is capable of sine wave generation to 100 MHz and square waves to 30 MHz, and there is a load of function and modulation possibilities, plus arbitrary waveform generation.

I liked that the waveform generators are easy to use with their fairly decent configuration menus. There’s a very usable palette of built-in waveforms, but any desired ones can be added for arbitrary waveform generation. Noise can be added to any waveform, including arbitrary waveforms, which is excellent.

Overall I think the entire waveform generating capabilities are just as flexible as standalone waveform generators, except that there’s no BNC sync output. That’s it! That is the only significant difference in typical everyday use, and the ease of use will mean I’m more likely to use the MXO 4 generator capabilities rather than reaching out for a standalone instrument.

As a first experiment, I decided to use the Frequency Response Analyzer (FRA), which is used for providing stimulus to a circuit-under-test and then observing the output from the circuit-under-test with respect to the input.

Frequency Response Analyzer: Audio Amplifier Characterization

I had a new design that I wished to test. Actually, it’s a very old design, from August 1971 Wireless World PDF (page 61), which I had constructed but had not tried out. It is an audio preamplifier that is supposed to be very good (at least for its time, maybe not now!) and I was curious to try it and hear what 1960’s/70's designs sounded like! The design accepts line or cartridge inputs and has analog volume, bass, and treble controls, whereas nowadays digital signal processing is used to adjust the sound to suit the speaker and the environment. I wanted to see what the frequency response was at different settings.

For this test, I connected up the MXO 4 waveform generator output using an SMA connector (I keep dozens of them handy for such tests; they are an easy way to connect to coax!) and also connected the generator to the ‘scope input channel 1 (with a BNC T-piece as shown in the diagram below), so that the reference was captured, to compare against the output which was connected to channel 2. For the output, I used the supplied ‘scope probe.

Note that although this testbed is fine for audio frequencies, care would be needed to ensure cable lengths are the same for higher-frequency tests.

The MXO 4 offers a built-in frequency response analyzer application, which can generate the stimulus and then use a couple of ‘scope channels to monitor the input and output signals, to determine the gain and phase. While it works, I figured this would also be a great opportunity to try out some of the instrument's programmability/remote control features. With the MXO 4’s Ethernet connector plugged into a network, the instrument was easy to access using Python. Of course, any other programming language or test solution could be used, such as NI LabVIEW, but for this exercise, I used Python.

It was found to be a pleasure to use the interface. Everything I tested worked the first time. The functionality is so useful, and it was nice to see a significant chunk of the user manual is dedicated to providing detail on each instruction that can be sent to the MXO 4.

Using it with Python is simple. I wrote a few functions in an audio_analyzer.py file. To connect to the instrument, just type:

import audio_analyzer as aaaa.open_instrument()

Next, to perform the signal generation and FRA measurements, type:

aa.do_scan()

Plot the FRA chart using:

aa.plot_chart()

Finally, exit by closing the connection to the MXO 4:

aa.close_instrument()

The charts below show the preamplifier frequency response. This all worked out well – I could modify the Python file for any future FRA requirement and keep the files for easily repeating tests in the future, as the circuit under test is further developed!

The response above was captured with the Bass control set to a minimum. By increasing the level of the Bass control, I could see the frequency response change (the y-axis gain scale is different in each of these screenshots):

Here’s the results with the Bass increased a little further, and the Treble control backed off a small amount, to get a reasonably flattened response to with half a dB or so (i.e. within about 5%):

The above was great news; the circuit seemed to be behaving, and more importantly, it had been confirmed that the MXO 4 remote control/programmability with Python code was a good method to use to capture and process results for any future circuit too. I now felt confident the instrument could be used for a variety of work, reliably generating signals and capturing data.

RF Mixer Testing

For this test, I wanted to see how useful the MXO 4 could be for working with RF circuits that often need waveform stimulus.

I had built a circuit that I wished to test; it is an RF mixer. Such mixers accept two inputs (the local oscillator input and the RF input), and the output contains the sum and difference frequencies.

Prior to the MXO 4, I would have needed around three items of test equipment for testing this circuit; a spectrum analyzer, a signal generator (usually spectrum analyzers have at best one signal source, but the mixer needs two), and an oscilloscope to see the time-domain view that is handy if it is desirable to see the diode behavior in action).

An ideal mixer (which doesn’t exist) would only have the sum and difference frequencies present, but in reality, there can be plenty of unwanted content. I set the MXO 4 waveform generator to 6 MHz at approximately -2 dBm, connected it to the local oscillator (LO) input of the mixer, and it was possible to view the spectrum to easily see that there was about 44 dB of isolation. In other words, about 1/25,000 of the power of the LO signal made it to the mixer output, which is hard to see in a time-domain view, but easy to see in the frequency domain!

Next, the second waveform generator was set to 5 MHz at about -22 dBm and connected to the RF input port. The screenshot below shows the mixer in action.

The trigger was surprisingly good at locking to the mixer output for a stable time-domain view. Incidentally, for flexibility in setting up my trigger, I used the trick of connecting the mixer output to a spare channel (channel 2 in this example) simultaneously, using a BNC T-piece. I was able to switch off the display of channel 2 to reduce screen clutter and concentrate on the signals of interest. By using a second channel, I could set the bandwidth separately and any other settings (if needed) to more precisely control what the trigger sees. I used an interval trigger and specified a minimum trigger width, all adjusted on-the-fly until the time-domain view was stable. This is actually all unnecessary to see the all-important frequency domain view for this test, but it is nice to get the time domain view looking stable to satisfy OCDs! : )

LoRa Testing: Arbitrary Waveform Generation

I love the arbitrary waveform generation capability. It is so simple to use compared to other ‘scopes and other waveform generators. In the past, it has been a pain having to use special software to create waveforms, or to try to fill the display with precisely one cycle of the waveform so that only whole periods of the waveform could be captured. The MXO 4 simplifies it all. In a nutshell, there is a simple CSV format with a header, and my general aim was to get the MXO 4 to create a CSV file for me, that I could then populate with whatever waveform was desired.

The easiest way to generate an arbitrary waveform is to simply create a list of values (you could use Python or MATLAB for instance) and then prepend with 43 lines of header content (which can be copy-pasted from any waveform saved by the MXO 4). Save it as a CSV file, and it can be imported into the instrument for replaying.

Incidentally, if the waveform that you wish to replay is already visible on the ‘scope, then you can use cursors to select the desired content to be repeated and set the values to act as a measurement ‘gate’. Then, the waveform is saved using that gate with just a few menu taps. The format is CSV, so it is easy to create and modify using custom tools. It’s perfect for capturing content and then modifying it if desired. Incidentally, the gate feature is very neat. It also has a lot of applications where you wish to perform operations on portions of content that the ‘scope is triggering on.

If required, any waveform saved into a file can be directly imported into MATLAB, but Python would work just as well. Excel could also be used since the waveform files are in plain CSV format.

Within the CSV file, the first 43 lines or so contain settings that can be copied. The remaining lines contain two columns of data: time values, and waveform voltage values.

I wanted to be able to generate LoRa signals, which have an unusual spread spectrum implementation known as Chirp Spread Spectrum (CSS). LoRa has become extremely popular for IoT solutions, so it would be great to be able to generate test signals for it!

These are usually transmitted at VHF or higher frequencies that are beyond the capability of the MXO 4 waveform generator (and most other arbitrary waveform generators). That’s not a problem; I could either use the two outputs with quadrature baseband signals, or I could use a single waveform generator channel, in both cases with external circuitry, to up-convert to a higher frequency range. For the single waveform generator option (which in effect is being used to generate intermediate frequency [IF] content), I’d just need an RF mixer (such as the one discussed earlier) and a local oscillator source. For a wireless transmission, the output would also need to be filtered.

The LoRa signal containing the message “Hello World!” was created using MATLAB, using the excellent LoRaMatlab code. The script file that I used is on GitHub, to run it, just type loragen to execute it and it will create a CSV file called mylora.csv. I then manually prepended the file contents with the header mentioned earlier (it was simple to copy-paste it in using Visual Code, but it could be automated in MATLAB if desired).

Uploading anything to the MXO 4 is very simple using the web interface; there is no need for any software utility to be installed.

The awesome spectrum view showed the LoRa transmission behavior, and it is possible to eyeball the approximate occupied bandwidth.

The channel bandwidth looks right according to MATLAB:

This is a great start, and it means it will be possible to use the MXO 4, along with an external RF mixer, for LoRa testing! I loved how simple this all was to do. I cannot imagine going back to a separate oscilloscope, signal generator, and spectrum analyzer unless I really need to.

Memory Depth, Logic, and Serial Bus Decode

Debugging Software and Protocol Stacks

I was keen to see if the MXO 4 could help software developers. A great benefit of the MXO 4 is that the entire sample data memory is available for logic data capture. For instance, if you have the additional memory option (MXO4-B108), then that’s (approximately) a pretty impressive 1,600 million samples available, and that is handy for capturing a massive amount of data bytes. However, nowadays, protocols are layered and complex, and one might not be interested in low-level bytes and frames alone; the higher-level protocol is also important.

The diagram below shows an example scenario where SPI serial data bytes are being used to access a file system in Flash memory.

There might be a thousand or more data bytes on the low-level SPI bus, just to open and read a few characters of information from a single file on that file system. There might be a group of bytes in a frame or transaction to send a particular command to the Flash memory, followed by more frames, and many dozens of them would be required to read a file. At each layer, there might be delays that need to be optimized and reduced, to increase the file system performance. I was curious if I could use the MXO 4 to identify such delays amongst the thousands of bytes, and then allow the user to trace them up to the higher layer because then it is clear to the software engineer responsible for that driver code, precisely which functions or operations they need to focus attention on, to improve performance.

For this test, I installed SPI Flash memory on a Pi Pico board and set up a file system called LittleFS. I wrote code on the Pi Pico that would use the file system to read a single file. More information on the setup is here. Probing with the MXO 4 logic probes, It could be seen that it took a total of 1286 SPI data bytes to read one line in a file, and those bytes were spread across 71 frames (transactions).

The MXO 4 provides a view that can be set up to look almost exactly like the diagram above.

The display of captured data is easy to view. You can set up the horizontal timebase to whatever value is convenient for displaying the entire high-level operation of interest, and then set up a zoomed-in view, for instance underneath it, if you wish to see the detail. Typically on other oscilloscopes this is a bit of a pain because the decode might not work if samples have not been captured with enough granularity for the zoomed-out high-level view. With the MXO 4 however, it is aware whenever a protocol is enabled, and a ‘dual path’ feature will automatically ensure that the decode can occur regardless of the scale of the zoomed-out view. It was therefore extremely simple to zoom out to see high-level transactions (such as file read and file write) at the top of the display, and drill down to see the frames directly underneath, and then see the frame content and signals.

It is very straightforward to gracefully adjust the protocol decode timing diagram, to go from a compressed view (where more than 70 bytes can be easily read off the screen per logic signal; one of the benefits of the HD resolution), to a more expanded view. The decode table below can also be used, of course.

It took a while to get my head around how best to use the record storage, primarily because in the past it’s been awkward trading off limited memory and acquisition rate with other oscilloscopes, and trust that everything is captured in sufficient detail. With the MXO 4, the easiest way for me to use the instrument was to simply make sure that the entire high-level operation is visible at the top, and then every data byte gets captured, without worrying about any other setting. The MXO 4 handles it all and ensures that the data is decoded. Note that there is protocol content trigger (and filter) capability, however there appears to be a bug in triggers longer than one byte, which I’ve reported to R&S. In the meantime, I found it no issue just to use the large amount of memory to capture the entire high-level transactions (which wouldn’t benefit from that type of trigger anyway, since there will be many repeated sequences amongst the hundreds of frames/thousands of bytes in a single high-level transaction).

Since the MXO 4 has segmented mode, there is the potential to capture even hours of capture however, I think this is not a supported use-case since it requires the segments to be able to be stopped at boundaries where no protocol data would be lost; I have proposed my use-case to R&S.

The data table can be navigated with a mouse to quickly check if the data looks about right, and then the entire data can be exported in 4 different formats, including XML and CSV. I found myself regularly using the HTML format since it was so quick to browse what was going on, and I liked the Python format for post-processing.

The Python-friendly format is extremely handy if you wish to do performance profiling of the protocol stack, or even for comparing captured data with a test dataset. This would be useful for spotting issues that might not be normally noticeable in some regression testing, for instance, if delays change slightly due to added code between software releases. A few dozen lines of Python code were sufficient to read the data captured from the MXO 4, and plot latency between data bytes across the SPI bus. I could immediately see where software development effort should be best expended to improve the speed of the file system. For instance, the chart below shows the timing for a file write operation (the operation wrote just two lines to a file!). More than 1800 bytes of SPI data were transferred to perform that high-level operation. Looking at the chart, it is clear that a large part of the time is spent polling. Hovering on any part of the chart with the mouse shows the MISO and MOSI message exchange at that point in time, along with the frame number so that it can be directly correlated with the decode table displayed on the MXO 4. The polling may be related to the Flash speed, however the initial first 17 milliseconds or so of the file write operation, when most of the 1800 bytes of the operation were transferred, could potentially be sped up with a faster SPI data rate and perhaps packing more than 20 bytes into a frame if possible, because from the chart it appears to be a hard-coded limit somewhere in the file system code.

The code is on GitHub; it accepts the SPI data saved by the MXO 4 in Python format and builds the chart with the content. I’m not entirely happy that I have the best chart design for examining SPI timings, I think it is possible to do much better. However, the chart is still a good start for understanding what is going on; I would never have known what the file write operation looked like in this detail otherwise. Going from thousands of data bytes and narrowing down to specific ones to see things like polling is now a breeze.

To summarize, realistically software can have delays, and many protocols are layered and complex. When there are thousands of SPI data bytes flying around, it really helped that the MXO 4 reliably captured all the data and allowed me to see every frame immediately. Python export is very helpful for post-processing. The MXO 4 is a powerful tool for software engineers to debug and optimize microcontroller source code. There were a few usability issues (sometimes it can get difficult to select a trace to drag with the finger when there are many traces on the display), but this was minor.

RS-485 DMX Testing

DMX (short for Digital Multiplex) is amongst the most useful protocols ever – DMX provides a convenient, industrial-environment-friendly way to control all manner of things, despite it originally being developed for lighting. DMX is transported using RS-485 signaling. Troubleshooting DMX is slightly complicated by the fact that there can be up to 512 bytes of data in a DMX packet, and it often repeats rapidly, so there’s a need to be able to drill-down into specific indexes into the 512-byte packet to identify if the associated devices are being fed the correct values. It might not be noticeable if there is the occasional flicker or glitch with LED lights, but often mechanical equipment such as camera lenses can be controlled with DMX too, and therefore it is important to test and be sure that the DMX output is rock solid.

For my use case, I had a DMX light with 9 LEDs to be controlled from a DMX controlling source microcontroller (Pi Pico) in a rather messy testbed for now:

Three MXO 4 features combine extremely well in this scenario; Trigger, History, and Segmented mode. These lend themselves well particularly to scenarios such as DMX where one may be interested in the output that occurred several seconds ago. Ordinarily, this would need a logic analyzer with a large capture buffer, but even then, it would be a pain to search through the tens of thousands of bytes of data!

With the MXO 4, I can set up the trigger to reliably capture the start of a DMX packet, and then the MXO dutifully labels each packet with a history counter value. The ‘fast segmentation’ feature allows the MXO 4 to capture in segments with no data loss!

For my test, I set up the Pi Pico to transmit to a 512-byte DMX ‘universe’ and cycle through RGB LED colors. In total, I was expecting 1200 DMX packets to be sent (each one containing 512 bytes), so a total of just over 600,000 bytes, and I didn’t want to lose a single bit of information, plus I wanted to be able to drill down into any particular packet at ease. The setup for this is shown in the screenshots below.

With all this set up, the normal Run/Stop and Single capture ‘scope buttons behave in a kind of “enhanced” mode compared to other manufacturers ‘scopes. The Single capture mode will actually just capture ‘forever’, until all memory segments are full, but you can stop it at any time when your test is complete, by just pressing it again. The Run/Stop button can be used to temporarily get out of the segmentation mode and behaves a bit more like any other normal ‘scope, which is convenient for quickly testing out changes, and then you can click on the Single capture button again, to get back into the segmentation mode which is where you want to be for running a test and not losing any packets from the start to the end of the test (provided you don’t exceed the ample memory of course).

After the test is complete, it is possible to step through every single packet! Not one packet was lost in the 1200 packets that I was expecting. The MXO 4 worked flawlessly for DMX decoding, although I did get into a situation a couple of times where the ‘scope would stop triggering. I am trying to find out how to replicate it, but the workaround was to save the configuration, and then hit the default button, and then reload the configuration. It just takes a few seconds but is annoying for sure that the underlying issue is there. It’s a reminder that this is still a new product (a new firmware build was released in the last few days of testing, so there is active development).

The screenshot below shows the controls that are available for switching between packets in the captured history.

The history control is the same as that used for analog signals (as discussed earlier in the review).

In summary the MXO 4 had no issue with the relatively large DMX packet sizes, and it was possible to capture more than a thousand packets (I only tested 1200) and still be able to select specific ones and examine individual bytes. This would be great for finely examining dynamic light-dimming changes or motorized equipment control (such as lenses) via DMX.

Order Codes

The base 200 MHz MXO 4 unit is either given the product code MXO44 or MXO44-242 or 1335.5050.04 for reasons I don’t understand. Anyway, it costs around $8400 USD or £7300 GBP at current prices, and it comes with four 700 MHz probes. The table below lists some available options and accessories, with the current prices at the time of writing.

Summary

Firstly, to address some negatives, it is a very new product, and I encountered bugs that have been reported to R&S, so hopefully they will be resolved in later firmware. During the two months of regular use, I have encountered no software crashes, and mostly I was able to work around most of the issues encountered; there was no show-stopper. In terms of the physical instrument and its accessories, I’m not too sure about the ruggedness of the ‘scope probes; users will need to take care not to break the tips I feel. There is a ‘Zone’ physical button that currently does nothing (it is for future use according to the user manual). I also kind of miss not having an ‘acquisition’ type of button on the ‘scope. I have to go into the menu for that, whereas a physical button for it (like on Tektronix ‘scopes, for instance) would be nice. A reconfigurable button would be a great feature; I suspect R&S will introduce that since there is a physical button labeled User that also is indicated for future use in the user manual.

Overall, the productivity with the oscilloscope has been great, it is generally easy to use, and it has performed competently with almost any task I threw at it, as can be seen from the various scenarios discussed in this review.

In terms of highlights, I loved the screen layout with the multiple windows and zoom capability. The screen size is really welcome. It is larger (and higher-res) than the display in other manufacturers’ 6000-series ‘scopes! It is all well organized, even though I occasionally had difficulty fine-tuning the positions of items with the user interface. I also really liked that high-quality captures were possible with multiple acquisitions, even in the single capture mode. The ability to see and playback acquisitions are something I’ve not seen before; it is very neat and well executed, and there is a dedicated History button for it on the 'scope so that users can make frequent use of this feature. The dual 16-bit waveform generation is excellent and very easy to use – better than some standalone arbitrary waveform generators! And the spectrum analyzer capabilities are outstanding. I also really loved the remote control capability; it was extremely smooth interfacing to the MXO 4, allowing the user to get the most out of the instrument. The protocol decode functionality and usability of it is pretty good, although it could be improved. The display of the data and the export capabilities are excellent, but I would like to see ways of segmenting the captured data for variable-length high-level transactions. I’ve documented this for R&S in case they are looking for ideas to improve that area of functionality in a later release.

There is functionality I could not hope to touch on in the review because the instrument is very feature-rich. For instance, the instrument features Spectrum Gate capability (which sounds a bit space-portal related, but that’s because it does feel very futuristic!). That capability will be highly useful for (say) investigating the causes of ringing on logic signals, but I get the feeling it is still a work in progress because the gate is a little hard to set up (as in all good sci-fi movies). I’ll revisit that if the latest release of firmware improves on that. Anyway, for now, the immediate task is to complete the video review.

Thanks for reading!